Fixes an information leakage vulnerability in the Search API where total_count was calculated before filtering out confidential features.

Root Cause / Motivation

During a security review, it was discovered that the total_count property of the Search API response was calculating the total number of features matching a query across the entire datastore before applying confidentiality filtering on the current page. This could be abused to leak the existence or total number of confidential features matching a specific query by an unprivileged user.

To fix this, internals/search.py now leverages a parallel datastore query to identify all confidential features matching the query, and filters out the ones the user doesn't have explicit permission to view from the result_id_set before the total_count is evaluated and the results are paginated.

Optimizations

1. Datastore Query Bypass: The parallel datastore query for confidential features and the subsequent filtering logic are now completely bypassed if the requesting user has global permissions to view all features (e.g., internal Google/Chromium accounts or site administrators). This prevents unnecessary database reads and processing.
2. Cache Partitioning: The Redis search cache is no longer fragmented by individual user emails. To preserve high cache hit rates and reduce memory bloat, the cache is partitioned by access level (global_access, no_access, or the user's email if they participate in any features). This ensures the majority of users safely share the same cached results.

Detailed Changelog

• internals/search.py:
  • Added confidential_future_ops to parallelize finding confidential features that matched the user's query. Those results are dynamically cross-checked with the user's view permissions, and explicitly stripped out of result_id_set prior to pagination and total count length check.
  • Optimized the search flow to skip confidential_future_ops and intersection filtering if is_google_or_chromium_account(user) or can_admin_site(user) is true.
  • Updated make_cache_key to partition cache entries by access level (global_access, no_access, or user email) rather than partitioning strictly by user email, restoring search cache performance.
• internals/search_test.py:
  • Updated test_make_cache_key assertions to use the expected no_access partition string instead of anonymous.